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METHOD AND SYSTEM FOR CONTROLLED 
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CROSS-REFERENCE TO RELATED APPLICATION 

This application claims the benefit of U.S. Provisional Application No. 60/104,31 1* 
entitled "METHOD AND SYSTEM FOR CONTROLLED DISTRTOUTION OF 
INFORMATION OVER A NETWORK", and filed on October 13, 1998, the disclosure of 
10 which is incorporated herein by reference for all purposes. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document contains material which is subject 
to copyright protection. The copyright owner has no objection to the facsimile reproduction 
15 by anyone of the patent document or the patent disclosure as it appears in the Patent and 
Trademark Office patent file or records, but otherwise reserves all copyright rights 
whatsoever. 

BACKGROUND OF THE INVENTION 

20 1. Field of the Invention 

The present invention relates to the management and exchange of information and, 
more particularly, to information management and exchange over networks. 

2. Description of the Related Art 

It is very common today for individuals to distribute or exchange business cards with 
25 others. Normally, the distribution or exchange of business cards occurs during the course of 
business; however, such distributions or exchanges can also occur in more personal settings. 

Business cards contain information pertaining to an individual who is normally 
associated with a business entity. The information on business cards typically includes a 
company name, an individual's name, title, phone number, facsimile number, mail address. 
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and email address. Business cards thus record the information that is needed to not only 
identify but also contact the individuals represented by the business cards. 

One problem with conventional approaches to distributing or exchanging business 
cards is that the information on the business cards often becomes outdated after their 

5 distribution. Typically, business cards become outdated when the individuals move offices, 
change employers, obtain promotions, etc. When the information on a particular business 
card does become outdated, the information no longer facilitates the contacting of the 
individual associated with the particular business card. The outdated inforaiation is often 
misleading. In general, the persons receiving the business cards cannot determine from the 

10 business cards whether the information on the business cards is still accurate. 

Another problem with conventional business cards is that their distribution is 
manual. As a result, for one's business card to be distributed, the business card needs to be 
physically handed to another person. Also, when a revised business card with updated 
information is to be distributed, often there is no way to know who currently holds an older 
15 version of the business card. As a result, inaccurate business cards remain in circulation 
long after being outdated. 

Thus, there is a need for improved approaches to automatically distribute and update 
contact information. 



Broadly speaking, the invention pertains to an information management and 
distribution system. The information management and distribution system include a client- 
side application and a server application that interact to facilitate the controlled exchange of 
contact information over a network. The client-side application can provide creation and 
25 design, rolodex, exchange, and update features. The information management and 
distribution system can also include a corporate administrator application. 

One aspect of the invention pertains to techniques for electronically distributing 
contact information over a network in a controlled manner. In one embodiment, the contact 
information includes information that is usefiil for identifying or contacting a registered user 
30 (e.g., person or entity). As an example, the contact information for a registrant can include 
name, telephone number, facsimile number, mail address, and email address. When the 
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registration pertains to a business, the contact information can also include a title, business 
name, and a Universal Resource Locator (URL) to an associated business website. A 
registered user that has received contact information pertaining to another registered user 
can contact the registered user using the contact information. 

5 Additionally, since contact information is dynamic and needs to be maintained, 

another aspect of the invention is the automatic update of the previously distributed contact 
information. Hence, should the contract information change after its distribution to certain 
registered users, then the updated contact information is able to be distributed to the certain 
registered users in an automated manner. 

10 Still another aspect of the invention is that contact information can be distributed to 

registered users in a common format. A common format for the distributed contact 
information can be used to facilitate a consistent type of contact information as w^ell as a 
consistent presentation of the contact information to registered users. In one example, the 
common format is provided by a business card arrangement. Further, the common format 

15 facilitates the association or attachment of additional information to the basic contact 

information. This additional information can include a wide variety of items. For example, 
the additional information can include text, data, hyper links, audio objects, video objects, 
etc. The additional information can also be used for a variety of purposes, including 
announcements, messages, notifications, and advertisements. 

20 Yet another aspect of the invention is the corporate administrator application. The 

corporate administrator application enables an administrator to control the use of corporate 
(i.e., business entity) information. The corporate administrator application can include many 
of the features associated with the client-side application, including creation and design, 
rolodex, exchange, and update features. For example, the administrator may wish to update 

25 the corporate information that has been previously distributed or exchanged. In addition, the 
corporate administrator application can facilitate registration of employees of a business 
entity with the information management and distribution system. The corporate 
administrator application can also disable certain employees from further use of the 
corporate information. 



3 




Att. Dkt. No.: CTClPOOl 

The invention can be implemented in numerous ways, including as a method, an 
apparatus, a computer readable medium, and a computer system. Several embodiments of the 
invention are discussed below. 

As a computer-implemented method for exchanging certain profile information over 
5 a network, the profile information being stored in a database and pertaining to a plurality of 
registered users, one embodiment of the invention includes the acts of: identifying a 
particular one of the registered users with which a requesting user desires to exchange 
profile information, the requesting user also being one of the registered users; informing the 
identified registered user via the network that the requesting user has requested to exchange 
10 profile information; receiving instructions from the identified registered user via the network 
on whether to permit the exchange of profile information with the requesting user; and 
thereafter exchanging profile information between the requesting user and the identified 
registered user from the database via the network in accordance with the instructions. 

In a network-based information exchange system, a computer-implemented method 
15 for exchanging electronic information in a controlled manner according to one embodiment 
of the invention includes the acts of: designating, by a requestor, a requested party with 
which an information exchange is desired; requesting, by the requestor, an information 
exchange with the requested party; and thereafter exchanging electronic information 
between the requestor and the requested party over a network to the extent permitted by the 
20 requested party. 

As a method for accessing a database of information across a network, one 
embodiment of the invention includes the acts of: registering users with a central system to 
store user information; receiving a request from a particular requesting user seeking to 
receive user information from the central system for a particular registered user; 
25 determining whether the particular registered user agrees to release of the user information 
associated with the particular registered user; and supplying the user information associated 
with the particular registered user from the central system to the particular requesting user to 
the extent permitted by the particular registered user. 

As a system for managing the exchange of dynamic information pertaining to 
30 persons, one embodiment of the invention includes: a system server that stores profile 

information for a plurality of registered users, manages the controlled exchange of portions 

4 
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information for a plurality of registered users, manages the controlled exchange of portions 
of the profile information between requestors and requestees, and facilitates the update to the 
profile information to the requested users whom have previously obtained the profile 
information being updated; a requestor's computer system capable of coupling to the server 

5 system through a network, the requestor's computer system selects one of the registered 
users to be a requestee for an exchange request; issues to the system server an exchange 
request for the profile information pertaining to the requestee, and stores the profile 
information pertaining to the requestee when the system server forwards the profile 
information pertaining to the requestee from the system server to the requestor's computer 

10 system; and a requestee's computer capable of coupling to the server system through a 
network, the requestee's computer system receives a permission request from the server 
system to permit an exchange of the profile information with the requestor, and sends a 
permission response to the server system indicating whether the request exchange of profile 
information is permitted. 

15 As a method for maintaining information stored in a remote database, the remote 

database includes information pertaining to a plurality of registered users, one embodiment 
of the invention includes the acts of: modifying pre-established information for a particular 
registered user stored in a local database of a local computing device; updating the remote 
database based on the modifications to the pre-established information; determining those of 

20 the registered users that have previously stored the pre-established information for the 

particular registered user in local databases of local computing devices associated with such 
registered users; and updating the local databases of the local machines associated with the 
registered users that have previously stored the pre-established information for the particular 
registered user, the updating being based on the modifications to the pre-established 

25 information. 

As an information management and distribution system, one embodiment of the 

invention includes: a system server that stores contact information for registered users and 

stores corporate contact information for business entities having employees; an administrator 

module that registers a business entity with the server system by providing the corporate 

30 contact information for the business entity, and the administrator controls registration of the 

employees of the business entity; and user modules that enable registered users to distribute 

their contact information to other registered users by way of the system server, the other 

5 





Att. Dkt. No.: CTClPOOl^^^p ^ 

modules, and in the case where the registered user is one of the employees of the business 
entity, the contact information that is distributed includes the corporate contact information. 

In an information management and exchange system having a plurality of registered 
users with each user having their own profile information, a method for controlling usability 

5 of previously received profile information for a registered user according to one embodiment 
of the invention includes the acts of: selecting one of the registered users to be disabled; 
identifying those of the registered users who have previously received profile information 
firom the selected registered user; and disabling use of the profile information for the 
selected registered user by those of the registered users whom have previously received the 

10 profile information firom the selected registered user. 

As a method for maintaining and distributing contact information for a business 
entity and employees of the business entity, one embodiment of the invention includes the 
acts of: creating contact information for a business entity; storing the contact information for 
the business entity on a system server; creating contact information for employees of the 
15 business entity, the contact information for the employees including some individual 

information and including or referencing the contact information for the business entity; 
storing the contact information for the employees of the business entity on the system 
server; and thereafl:er distributing the contact information for one or more of the employees 
to one or more recipients. 

20 As a graphical user interface presented on a display device, one embodiment of the 

invention includes a card display area for displaying a contact card, the contact card 
including contact information for the user. The graphical user interface can further include a 
selector that allows a user to select one of a plurality of contact cards or an additional 
information designation area that indicates whether there are any additional cards associated 

25 with the contact card being displayed. 

The advantages of the invention are numerous. Several advantages that 
embodiments of the invention may include are as follows. One advantage of the invention is 
that the distribution of information takes place in an automated fashion, which is particularly 
advantageous when large numbers of users are involved. Another advantage of the 
30 invention is that the parties involved in the distribution can control the distribution process 
so that only approved distributions occur. Still another advantage of the invention is that 
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SO that only approved distributions occur. Still another advantage of the invention is that 
updates to previously distributed information can also be automated. Yet another advantage 
of the invention is that the information being exchanged is useful for enabling registered 
persons to efficiently contact the persons associated with the information using a mechanism 
which they have prescribed. Another advantage of the invention is that contact and 
additional information can be distributed to users in a common format. Still yet another 
advantage of the invention is that an administrator can control the distribution and use of 
corporate (i.e., business entity) information. 

Other aspects and advantages of the invention will become apparent from the 
following detailed description taken in conjunction with the accompanying drawings which 
illustrate, by way of example, the principles of the invention. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be readily understood by the following detailed 
description in conjunction with the accompanying drawings, wherein like reference 
numerals designate like structural elements, and in which: 

FIG. 1 is a block diagram of a network information management and distribution 
system according to an embodiment of the invention; 

FIG. 2 is a block diagram of a server machine according to an embodiment of the 
invention; 

FIG. 3 is a block diagram of a local machine according to an embodiment of the 
invention; 

FIG. 4 is a flow diagram of automatic contact information distribution processing 
according to an embodiment of the invention; 

FIG. 5 is a flow diagram of client on-line registration processing according to an 
embodiment of the invention; 

FIGs. 6A and 6B are flow diagrams of server registration processing according to an 
embodiment of the invention; 

FIG. 7 is a flow diagram of general client-side application processing according to an 
embodiment of the invention; 
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FIG. 8 is a flow diagram of local registration processing according to an embodiment 
of the invention; 

FIG. 9 is a flow diagram of business card creation processing according to an 
embodiment of the invention; 
5 FIG. 10 is a flow diagram of rolodex processing according to an embodiment of the 

invention; 

FIG. 1 1 is a flow diagram of requestor exchange processing according to an 
embodiment of the invention; 

FIGs. 12A and 12B are flow diagrams of requested party exchange processing 
10 according to an embodiment of the invention; 

FIG. 13 is a flow diagram of requestor exchange completion processing according to 
an embodiment of the invention; 

FIG. 14 is a flow diagram of requested party exchange processing through electronic 
email according to an embodiment of the invention; 
15 FIG. 15 is a flow diagram of change profile processing according to an embodiment 

of the invention; 

FIG. 16 is a flow diagram of update profile processing; 

FIG. 17 is a flow diagram of initial server connection processing according to an 
embodiment of the invention; 
20 FIG. 1 8 A- 1 8K are screen illustrations associated with a representative embodiment 

of the invention; 

FIG. 19A is a representative screen illustration of a rolodex featiure according to 
another embodiment of the invention; 

FIG. 19A-1 is a representative screen illustration of an additional card of information 
25 according to an exemplary embodiment of the invention; 

FIG. 19B is a block diagram of a network information management and distribution 
system according to another embodiment of the invention; 

FIG. 20 is a flow diagram of corporate administrator application 
processing according to an embodiment of the invention; 
30 FIG. 21 is a flow diagram of local corporate registration processing according to an 

embodiment of the invention; 
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FIG. 22 is a flow diagram of employee association processing according to an 
embodiment of the invention; and 

FIG. 23 is flow diagram of notification and disable processing according to an 
embodiment of the invention. 

5 

DETAILED DESCRIPTION OF THE INVENTION 

The invention relates to techniques for electronically distributing contact information 
over a network in a controlled manner. In one embodiment, the contact information includes 
information that is useful for identifying or contacting a registered user (e.g., person or 

10 entity). As an example, the contact information for a registrant can include name, telephone 
number, facsimile number, mail address, and email address. When the registration pertains 
to a business, the contact information can also include a title, business name, and a Universal 
Resource Locator (URL) to an associated business website. A registered user that has 
received contact information pertaining to another registered user can contact the another 

15 registered user using the contact information. 

Additionally, since contact information is dynamic and needs to be maintained, the 
invention can also cause the automatic update of the previously distributed contact 
information. Hence, should the contract information change after its distribution to certain 
registered users, then the updated contact information is able to be distributed to the certain 
20 registered users in an automated manner. Further, the contact information can be distributed 
to registered users to have a common format. A common format for the distributed contact 
information can be used to facilitate a consistent type of contact information as well as a 
consistent presentation of the contact information to registered users. In one example, the 
common format is provided by a business card arrangement. 

25 In one embodiment, a requestor requests to receive the contact information from a 

requested party, and the requested party is asked whether the requestor can receive the 
contact information of the requested party. The contact information of the requested party is 
then distributed to the requestor only when the requested party agrees to the request. Once 
receiving the contact information pertaining to the requested party, the requestor can use the 

30 contact information to contact the requested party. If the contact information were to 
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subsequently be changed by the requested party, the previously distributed contact 
information can be updated. 

Embodiments of this aspect the invention are discussed below with reference to 
FIGs. 1-23. However, those skilled in the art will readily appreciate that the detailed 

5 description given herein with respect to these figures is for explanatory purposes as the 
invention extends beyond these limited embodiments. 

FIG. 1 is a block diagram of a network information management and distribution 
system 100 according to an embodiment of the invention. The network information 
management and distribution system 100 includes a server machine 102, a requestor 

10 machine 104 and a requested party machine 106. The Internet 108 is used to interconnect 
the server machine 102 with the requestor machine 104 and the requested party machine 
106. The requestor machine 104 connects to the Intemet 108 through an intermediate 110, 
and the requested party machine 106 connects to the Intemet 108 through an intermediate 
112. The intermediates 110 and 112 can refer to any of a nxmiber of networks or network 

15 devices, including a Local Area Network (LAN), a corporate Intranet, a Wide Area Network 
(WAN), a wireless data network, and an Intemet Service Provider (ISP). It should be noted 
that other networks besides the Intemet can be used to interconnect the server machine 102 
with the requestor machine 104 and the requested party machine 106. 

The server machine 102 provides for storage and management of content 

20 information. The content information pertains to a plurality of users, including the user of 
the requestor machine 104 and the user of the requested party machine 106. For example, 
content information for the user of the requestor machine 104 can be supplied to the server 
machine 102 through the intermediate 110 and the Intemet 108. Likewise, content 
information for the user of the requested party machine 106 can be supplied to the server 

25 machine 102 through the intermediate 112 and the Intemet 108. The server machine 102 
stores the received content information for subsequent distribution. 

The distribution of the content information at the server machine 102 can be 
performed as follows. First, the user of the requestor machine 104 makes a request for 
contact information to the server machine 102 through the Intemet 108. Second, when the 

30 server machine 102 receives the request from the requestor machine 104, the server machine 
102 determines that the requestor is seeking to receive the contact information for the user of 
the requested party machine 106. The server machine 102 than proceeds to query the user of 

10 
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the requested party machine 106 whether the distribution of its contact information is 
permitted. If the user of the requested party machine 106 repUes that the distribution is 
permitted, then the server machine 102 forwards the contact information for the user of the 
requested party machine 106 from the server machine 102 to the requestor machine 104 

5 through the Intemet 108. Upon receiving the contact information for the user of the 
requested party machine 106, the requestor machine 104 locally stores the contact 
information in the requestor machine 104. Alternatively, if the user of the requested party 
machine 106 replies that the distribution is not permitted, then the server machine 102 sends 
a notification to the requestor machine 104 to inform the user that the request for contact 

10 information from the user of the requested party machine 106 is denied. Optionally, instead 
of the one-way distribution of the contact information, contact information of both users of 
the requestor machine 104 and the requested party machine 106 can be exchanged (i.e., two- 
way distribution). 

Accordingly, the distribution of contact information is controlled by the "owner" of 

15 the information. As such, contact information is able to be electronically transmitted to 
those users that are approved and not to those users that are not approved. Additionally, 
should the contact information need to be changed, the changes can be made and then the 
server machine can proceed to update the previously transmitted contact information. As an 
example, the updating of the contact information at the requested party machine 106 

20 produces altered contact information that is forwarded and stored on the server machine 102. 
Then, the server machine 102 can distribute the altered content information through the 
Intemet 108 to all of those requestors machines that previously received (and this store) the 
contact information which is. now outdated, thereby updating the content information for the 
user of the requested party machine 106 on the various requestor machines. 

25 The network information management and distribution system 100 is described in 

more detail below as an information management and exchange system wherein the contact 
information is exchanged (two-way distribution) between the users of the requestor machine 
104 and the requested party machine 106. Also described in detail below are the creation 
and modification of contact information, and the use of the contact information on the local 

30 machines. 

FIG. 2 is a block diagram of a server machine 200 according to an embodiment of 
the invention. The server machine 200 is, for example, suitable for use as the server 
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machine 102 illustrated in FIG. 1. The server machine is also referred to as a remote server 
or a system server. 

The server machine 200 includes a server controller 202 that controls the operation 
of the server machine 200 v^ith respect to providing the operations of the invention. The 

5 server controller 202 couples to the Intemet 108 through a netv^ork interface 204. The 
server controller 202 also interacts with a registration manager 206, an exchange manager 
208, and a contact information manager 210. The registration manager 206 manages the 
registration of users w^ith the information management and exchange system. The 
registration manager 206 makes use of a client application (client-side application) that is 

10 available for download to the users that have (or will) register with the information 
management and exchange system. The registration manager 206 also makes use of a 
personal identifier (PED) generator 214. The PID generator 214 is used to generate unique 
identifiers for the users that are registered with the information management and exchange 
system. The exchange manager 208 and the contact information manager 210 couple to a 

15 server contact information storage 216. The server contact information storage 216 provides 
storage for the contact information for each of the registered users. In one embodiment, the 
contact information is profile information. The exchange manager 208 manages the 
exchange of particular contact information between registered users. The contact 
information manager 210 manages the storage of the contract information for the registered 

20 users as well as the subsequent update to the contact information. 

The server controller 202 can include a Hyper Text Transfer Protocol (HTTP) server 
that allows assess and retrieval of information with respect to a website associated with the 
information management and exchange system. The website is stored in website storage 
218. 

25 FIG. 3 is a block diagram of a local machine 300 according to an embodiment of the 

invention. The local machine 200 is, for example, suitable for use as the requestor machine 
104 and the requested party machine 106 illustrated in FIG. 1. 

The local machine 300 includes a client controller 302 that controls the operation of 
the local machine 300 with respect to the operation of the invention. The client controller 

30 302 couples to the Intemet 108 through a communication manager 304. The client 

controller 302 runs or executes a client-side application 306 and displays information for a 
user on a display device 308. The client-side application 306 includes a registration process 
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310, an exchange process 312, and contact information creation/update process 314. The 
registration process 310 is used by a user of the local machine to register with the 
information management and exchange system. The exchange process 312 manages 
commimications between the client-side application 306 and the server machine 102 so as to 
request and then, if approved, to receive contact information for a particular user. The 
contact information that may be received is stored in a local contact information storage 316. 
The contact information creation/update processing 314 allows the user of the local machine 
300 to create and update their own contact information. The contact information 
creation/update processing 314 also communicates with the server machine 102 so that the 
various local machines of the information management and exchange system can have their 
previously exchanged contract information updated. The local contact information storage 
316 also stores the contact information for the user of the local machine 300. Additionally, 
the local machine 300 typically includes a network browser 318 that allows the local 
machine to access the website of the information management and exchange system, such as 
provided by the server machine 102. 

FIG. 4 is a flow diagram of automatic contact information distribution processing 
400 according to an embodiment of the invention. The automatic contact information 
distribution processing 400 is, for example, performed by the network information 
management and distribution system 100. 

The automatic contact information distribution processing 400 begins by registering 
402 a plurality of users with their contact information (e.g., profile information). Then, at 
the request of users, contact information is electronically exchanged 404 between consenting 
users. The exchange of the contact information takes place over a network (e.g., the 
Internet). The contact information being exchanged pertains to the parties participating in a 
particular exchange. In one embodiment, each particular exchange of the contact 
information is between a pair of users that have consent to the particular exchange. After the 
contact information is exchanged, the consenting users have the contact information of each 
other and thus are able to thereafter utilize the contact information to contact the user 
associated with the contact information. 

The users that have distributed their contact information with others may 
subsequently alter their contact information in any of a number of ways. For example, the 
contact information can include a name, mail address, telephone nmnber, facsimile number. 
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and email address. If the telephone number of a particular user changes, then the particular 
user is able to update their contact information so as to contain the correct telephone 
number. However, at least the portion of the contact information that has been changed 
needs to be distributed to those of the users that have previously received the contact 

5 information of the particular user. In any case, with respect to the automatic contact 
information distribution processing 400, when users do subsequently alter their contact 
information, the altered contact information is received 406 from the associated users. Then, 
the previously exchanged contact information is electronically updated 408 to be consistent 
with the altered contact information. Following block 408, the automatic contact 

10 information distribution processing 400 is complete and ends. 

The operations of the information management and exchange system is described in 
greater detail below with respect to FIGs. 5-23. 

FIG. 5 is a flow diagram of client on-line registration processing 500 according to an 
embodiment of the invention. The client on-line registration processing 500 is, for example, 
15 performed by a network browser (i.e., web browser) running on a local machine. 

The client on-line registration processing 500 initially visits 502 a server website that 
is hosting an information management and exchange system, such the server machine 200. 
Next, the network browser receives and displays 504 a registration page (e.g., HTML page). 
The registration page allows a user to not only download a client-side application but also 
20 register on-line with the information management and exchange system. 

After the registration page is displayed 504, a decision block 506 determines whether 
the user has requested on-line registration. When the user has requested on-line registration, 
the network browser requests 508 a profile page from the server website. The network 
browser then receives and displays 5 1 0 the profile page provided by the server website. The 
25 profile page is a form that is displayed and permits data entry into various fields. As an 

example, the profile page can be a Hyper Text Markup Language (HTML) page. FIG. 18A 
is a screen illustration of a representative profile page according to an embodiment of the 
invention in which various fields are provided for data entry of business and/or personal 
information. 

30 The user then completes 512 the profile page which queries the user for profile 

information. The profile information is, for example, descriptive information that the user 
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represents about themselves. As an example, the profile information can include name, title, 
business name, mail address, email address, telephone number, facsimile number, and 
Universal Resource Locator (URL). After the user has completed the profile page, the 
profile information is submitted 514 to a system server via a submitted profile page request. 
5 The profile information defines a profile for the registrant (user). The system server 
manages the profile information and may be the same server, or group of servers, as 
providing the server website. In one embodiment, the submitted profile page request can be 
considered a POST operation in Hyper Text Transfer Protocol (HTTP). 

Next, a decision block 516 determines whether the profile has been accepted by the 
10 system server. When the decision block 516 determines that the profile has not been 

accepted, the network browser receives and displays 518 an error page. Following block 
518, the client on-line registration processing 500 retums to repeat block 512 and subsequent 
blocks such that the user can again repeat the completion of the profile page or modify 
previously entered data (profile information). 

15 Once the decision block 516 determines that the system server has accepted the 

profile, the network browser requests 520 a registration download application page fi-om the 
system server. The registration download application page is a page (e.g., HTML page) that 
facilitates the user in downloading the client-side application firom the system server. Next, 
the network browser receives 522 the downloaded client-side application, a personal 

20 identifier (PID) file, and profile information pertaining to the user's profile. The client-side 
application is an application program that executes on the local machine as the client side of 
the information management and exchange information. The PID file contains a imique 
identifier that is associated to the user (requestor). The profile information is the 
information about the user that has been previously submitted by the user. In other words, 

25 the profile information is the self-represented data provided by the user in block 512. Next, 
the downloaded client-side application, the PID file and the profile information that have 
been received 522 are stored 524 on the local machine. Following block 524, the client on- 
line registration processing 500 is complete and ends. 

On the other hand, when the decision block 506 determines that the user has not 
30 selected or requested on-line registration, then the client on-line registration processing 500 
allows the user to obtain the client-side application without undergoing on-line registration. 
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In such case, a decision block 528 initially determines whether the user is requesting to 
download the client-side application. When the decision block 528 determines that the user 
is not requesting to download the client-side application, then other processing is performed 
in block 526. The other processing can be a variety of different processes or operations that 

5 are either conventionally performed or not related to the invention. As an example, the other 
processing can be viewing other pages available from the server website via the network 
browser. Following block 526, the client on-line registration processing 500 retums to 
repeat the decision block 506 and subsequent blocks so that the server machine is essentially 
awaiting the user to select either on-line registration or to select a request for downloading 

10 the client-side application. 

When the decision block 528 determines that the user has selected to download the 
client-side application, then an unregistered download application page is requested 530 
from the system server. Then, the downloaded application is received 532 at the network 
browser. Once the downloaded application is received, the client-side application is stored 
15 534 on the local machine. Following block 534, the client on-line registration processing 
500 is complete and ends. 

FIGs. 6A and 6B are flow diagrams of server registration processing 600 according 
to an embodiment of the invention. The server registration processing 600 is, for example, 
performed by the server machine (server system) in connection with the invention. 

20 The server registration processing 600 begins with a decision block 602 that 

determines whether a page request has been received. If a page request has not yet been 
received, the decision block 602 causes the server registration processing 600 to await the 
receipt of a page request. In other words, the server registration processing 600 is invoked 
when a page request is received. 

25 Once a page request has been received, a decision block 604 determines whether the 

received page request is a registration request. When the decision block 604 determines that 
the received page request is a registration page request, a registration page is sent 606 to the 
requestor. Here, for example, the registration page request can be a HTTP request to the 
server machine which, in response, supplies the registration page (HTTP response) to the 

30 requestor. Following block 606, the server registration processing 600 retums to repeat the 
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decision block 602 and subsequent blocks so that additional page requests can be processed 
by the server machine. 

On the other hand, when the decision block 604 determines that the received page 
request is not a registration page request, a decision block 608 determines whether the 

5 received page request is a profile page request. When the decision block 608 determines 
that the received page request is a profile page request, then the server machine sends 610 a 
profile page to the requestor. The profile page allows the requestor (user) to profile 
him/herself and then return the completed profile to the server machine. As an example, the 
profile page request is a HTTP request. Following block 610, the server registration 

10 processing 600 retums to repeat the decision block 602 and subsequent blocks so that 
additional page requests can be processed by the server machine. 

Alternatively, when the decision block 608 determines that the received page request 
is not a profile page request, then a decision block 612 determines whether the received page 
request is a submitted profile page request. The submitted profile page request represents a 

15 submission of a profile by the requestor in accordance with a previously supplied profile 

page that has been completed. As an example, the submitted profile page request is a HTTP 
request. When the received page request is determined to be a submitted profile page 
request, then the server registration processing 600 operates to process the submitted profile 
provided by the requestor. Specifically, the server machine examines 614 the submitted 

20 profile. Then, a decision block 616 determines whether there are errors or deficiencies 
associated with the submitted profile. When the decision block 616 determines that there 
are errors or deficiencies in the submitted profile, then an error page is sent 618 to the 
requestor. Following block 618, the server registration processing 600 retums to repeat the 
decision block 602 and subsequent blocks. The requestor is then able to correct and 

25 resubmit his/her profile information. 

On the other hand, when the decision block 616 determines that there are no errors or 
deficiencies with the submitted profile, then a decision block 620 determines whether the 
associated requestor is already registered with the system. When the decision block 620 
determines that the requestor is already registered with the system, then the server machine 
30 sends 622 an already registered page to the requestor. The already registered page informs 
the requestor that he or she is already registered with the system and thus the submitted 
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profile is not utilized. Following block 622, the server registration processing 600 returns to 
repeat the decision block 602 and subsequent blocks. 

Alternatively, when the decision block 620 determines that the requestor is not yet 
registered with the system, then the profile information provided in the submitted profile is 
stored 624 in the system database (e.g., server contact information storage 216). Next, the 
server machine operates to assign 626 a PID to a requestor. The PID is a unique number for 
each requestor (user). Next, the PID is associated 628 with the profile information for the 
requestor in the system database. The association 628 operates to link together the profile 
information of the requestor with the PID of the requestor such that fiiture references to the 
requestor can be achieved using the PID. Following block 628, a registered download page 
is sent 630 to the requestor. Following block 630, the server registration processing 600 
retums to repeat the decision block 602 and subsequent blocks. 

On the other hand, when the decision block 612 determines that the received page 
request is not a submitted profile page request, a decision block 632 determines whether the 
received page request is a registered download application page request. The registered 
download application page request is a request (e.g., HTTP request) to dovmload the client- 
side application to the requestor. When the decision block 632 determines that the received 
page request is a registered dovmload application page request, then the server machine 
doAvnloads 634 the client-side application along with the PID file and profile information to 
the requestor. Following block 634, the server registration processing 600 retums to repeat 
the decision block 602 and subsequent blocks. 

Alternatively, when the decision block 632 determines that the received page request 
is not a registered download application page request, then a decision block 636 determines 
whether the received page request is an unregistered download application page request. 
The unregistered download application page request is a request (e.g., HTTP request) to 
download the client-side application to the requestor. When the decision block 636 
determines that the received page request is an unregistered dovraload application page 
request, then the server machine downloads 638 the client-side application to the requestor. 
Following block 638, or following the decision block 636 when the received page request is 
determined not to be an unregistered download application page request, the server 
registration processing 600 retums to repeat the decision block 602 and subsequent blocks. 
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While the server machine may also service additional page requests beyond those illustrated 
and described with the respect to FIGs. 6A and 6B, such additional page requests are not 
associated with the present invention and therefore are not discussed herein because they 
would obscure the operation of the invention. 

5 Upon receiving the client-side application at the local machine, a requestor would 

install the client-side application on their local machine. As is well knovm in the art, the 
client-side application can be dovmloaded from the server machine (system server) to the 
local machine in a self-extracting format such that a user simply executes a file and the 
installation of the client-side application is performed. The client-side application would 

10 install itself in a predetermined directory and would also store the PID file and profile 

information in that same directory if such additional information was also downloaded from 
the server machine. Additionally, after the installation procedure has installed the program, 
typically a desktop icon would be provided in a start menu as well as on the visible desktop. 

FIG. 7 is a flow diagram of general client-side application processing 700 according 

15 to an embodiment of the invention. The general client-side application processing 700 is, 
for example, performed by the client-side application running on the local machine. 

The general client-side application processing 700 initially begins upon execution of 
the client-side application. Once the client-side application is started, the general client-side 
application processing 700 operates to search 702 for a PID file on the local machine. The 

20 presence or absence of PED file indicates whether or not the user of the local machine has 
already registered with the system server of the information management and exchange 
system. A decision block 704 determines whether the PID file has been foimd on the local 
machine. When the decision block 704 detemiines that the PID file has not been foxmd, 
local registration processing is performed 706 so that the user can register with the system 

25 server of the information management and exchange system (see FIG. 8). Following block 
706, the general client-side application processing 700 is restarted. Hence, only registered 
users are able to use the client-side application in its normal operating sense. 

On the other hand, when the decision block 704 determines that the PID file has been 
foimd on the local machine, the local machine is connected 708 to the server machine. Here, 

30 the connection of the local machine to the server machine can be performed in a variety of 

ways. For example, the connection is often through ports of the local machine and the 

server machine using some sort of commimication protocol, such as HTTP or TCP/EP. In 
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one embodiment, as shown in FIG. 1, the connection is provided using the Intemet. The 
connection can also be established at least in part over a public telephone network (PTN), a 
wireless network, a LAN or WAN. 

Once the general client-side application 700 is executing, the client-side application 

5 is able to process both user events and server events. The user events are provided by a user 
of the local machine, and the server events are provided by the server machine to the local 
machine via the connection. Following the connection (block 708) of the local machine to 
the server machine, a decision block 710 determines whether a user event has been received. 
When the decision block 710 determines that a user event has been received, the user event 

10 is processed 712. Alternatively, when the decision block 710 determines that a user event 
has not been received, a decision block 714 determines whether a server event has been 
received. When the decision block 714 determines that a server event has been received, the 
server event is processed 716. The user and server events cause the client-side application to 
perform actions that are associated with processing performed by the client-side application, 

15 such processing includes business card creation, rolodex operations, exchange operations, 
and update operations. Then, following the block 712, the block 716, or the decision block 
714 when a server event is not received, a decision block 718 determines whether the user is 
requesting to exit the general client-side application processing 700. When the decision 
block 718 determines that an exit is requested, the general client-side application processing 

20 700 is complete and ends. On the other hand, when the decision block 718 determines that 
the user is not requesting to exit, then the general client-side application processing 700 
retums to repeat the decision block 710 and subsequent blocks. 

As previously noted, a user of the information management and exchange system is 
required to register with the system in order to participate in using its information 

25 management and exchange features. As was explained with respect to FIGs. 6 A and 6B, the 
registration processing can be initiated and performed through a website server. 
Alternatively, the registration processing can be performed by the client-side application. 
Specifically, upon initially invoking the client-side application on a local machine, the 
client-side application can request that the user register with the information management 

30 and exchange system (see block 706, FIG. 7). 
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FIG. 8 is a flow diagram of local registration processing 800 according to an 
embodiment of the invention. The local registration processing 800 is, for example, 
performed by the block 706 illustrated in FIG. 7 for the general client-side application 700. 

The local registration processing 800 initially displays 802 a profile screen on the 
5 local machine. The profile screen would contain a form that the user would complete by 
entering profile information. Typically, the profile screen would be visually similar to the 
profile page used above with respect to FIGs. 6A and 6B. For example, a representative 
profile screen can be similar to the screen illustration shown in FIG. 18 A. 

A user then completes 804 their profile using the profile screen. Next, a decision 

10 block 806 determines whether the user has submitted their profile to the server system. 
When the user has not yet submitted their profile to the server system, the decision block 
806 causes the local registration processing 800 to await the user's request to submit the 
profile. Once the decision block 806 determines that the user has submitted their profile, the 
local machine is connected 808 to the server machine. Once connected, the profile 

15 information is sent 810 to the server machine. 

A decision block 812 then determines whether the profile has been accepted by the 
server system. When the decision block 812 determines that the server system rejects the 
profile, then an error screen is displayed 814 on the local machine. The error screen informs 
the user of the local machine that the profile that has been submitted is not acceptable. 

20 Following block 814, the local registration processing 800 retums to repeat the block 804 
and subsequent blocks so that the user is able to modify their profile so as to eliminate the 
errors identified by the server system. 

On the other hand, when the decision block 812 determines that the profile has been 
accepted by the server system, a PID file is received 816 from the server machine. Here, the 

25 server system operates, after receiving the submitted profile, to generate a suitable PID file. 
The PID file is then sent fi-om the server system to the local machine. After receiving 816 
the PID file, the PID file is stored 818 in the local machine. The user is then instmcted 820 
to restart the client-side application. Upon restart, the client-side application processing 700 
will identify the stored PID file on the local machine (block 702, FIG. 7) and thus allow the 

30 client-side application to perform the operations associated with information management 
^ and exchange system. Following block 820, the local registration processing 800 is 
complete and ends. 

21 






Att. Dkt. No.: CTClPOOl ^ 

The client-side application provides a number of features that are available to a user. 
One such feature pertains to the design and creation of electronic business cards. Electronic 
business cards are used as a medium for containing information. The information contained 
in the cards is, for example, contact information about the individual represented by a 

5 particular business card. In effect, the electronic business cards are containers for 

information that has a common format. More generally, the contact information is presented 
to the users in a common format. With the common format, a consistent presentation of 
contact information (e.g., profile information) can be made to registered users. Electronic 
business cards are one example of the common format. 

10 FIG. 9 is a flow diagram of business card creation processing 900 according to an 

embodiment of the invention. The business card creation processing 900 is, for example, 
utilized by a user of the client-side application in designing and creating a business card that 
would contain their profile information and be used to distribute to others in a controlled 
fashion. 

15 The business card creation processing 900 initially displays 902 business card format 

templates. FIG. 18B is a representative screen illustration showing exemplary business card 
format templates. A user of the client-side application at the local machine is then able to 
select one of the business card formats (or layouts) to be used for their business card. 
Hence, a decision block 904 determines whether a template has been selected. When the 

20 decision block 904 determines that a template has not been selected then, presumably, the 
user has decided to custom design their own business card format. In this case, the user 
designs 906 the business card format using conventional text and line drawing tools. 
Following the block 906, or directly following the decision block 904 when the user has 
selected a template, a decision block 908 determines whether the user desires to include 

25 graphics within their business card design. When the decision block 908 determines that 
graphics are to be included in the business card design, a graphic image is obtained 910. A 
graphic image can be obtained in a variety of ways, including scanning an image, selecting 
an image from pre-stored images, or otherwise importing an image. As an example, the 
graphic image can be a company logo or some other symbol to be provided on the business 

30 card design. Once the graphic image is obtained 910, the graphic image is fitted and placed 
912 on the business card design. Following block 912, as well as following the decision 
block 908 when graphics are not desired, a decision block 914 determines whether 
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additional text is desired. When the decision block 914 determines that additional text is 
requested, then text can be added 916 to the business card design. Again, the addition of 
text onto the business card design can use conventional text tools. Following block 916, as 
well as following the decision block 914 when additional text is not to be added, a decision 
block 918 determines whether the user has requested to submit their business card design. 
Here, a submission of the business card design means that the design is finalized and the 
user is ready to transmit it to the server system for subsequent use and exchange with others. 
When the decision block 918 determines that the user has not requested to submit the 
business card design, the user is able to edit 920 the business card design and make any 
desired changes to the design. Following block 920, the business card creation processing 
900 retums to repeat the decision block 918. Once the decision block 918 determines that 
the user has requested to submit the business card design, the business card design is sent 
922 to the server system. At the server system, the business card design will be stored so 
that the server system has access to the business card designs for all the users. The business 
card design is also saved 924 at the local machine so that it is locally available. Following 
block 924, the business card creation processing 900 is complete and ends. The user of the 
client-side application is also able to subsequently change their business card design or 
profile information thereon as described below. 

Another feature of the client-side application is a rolodex feature. The rolodex 
feature allows a user of the client- side application to view the various profiles (e.g., business 
cards) it has received during exchanges. In addition to viewing the various profiles, the 
rolodex feature can be used to contact the individuals associated with the profiles. These 
various profiles can also be categorized, deleted, referenced and searched in a variety of 
ways. Additionally, when the profiles have been subsequently changed or otherwise 
updated, these updates can occur in a variety of different ways as discussed below. 

FIG. 10 is a flow diagram of rolodex processing 1000 according to an embodiment 
of the invention. The rolodex processing 1000 is performed on the client-side application. 
The rolodex processing 1000 initially selects a contact card associated with an entity to be 
contacted. The client-side application typically stores numerous contact cards. Hence, the 
selection may make use of some searching through the cards or placing the cards into 
categories to facilitate the selection of a desired one of the contact cards. 
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The contact card is a card that includes contact information for an entity. The entity 
is typically an individual, but the individual may be associated a personal side or a business 
side. In one embodiment, the contact card appears as a small, hand-sized electronic business 
card that contains contact information when displayed. Examples of the contact information 

5 (or profile information) include name, company, title, address, telephone number, facsimile 
number, email address, and URL. 

FIG. 18C is a screen illustration of a representative rolodex feature according to an 
embodiment of the invention. An icon 1808 is used to select the rolodex feature. In the 
screen illustration, the selection of the contact card is performed in contact card selection 

1 0 window 1810. Category area 1812 and search area 1 8 1 4 are used by a user to narrow the 
number of possible contact cards to choose from in the contact card selection window 1810. 
Once the contact card is selected, the selected contact card is displayed in a card display area 
1816. The card display area 1816 displays the selected contact card with its contact 
information. In this embodiment, the selected contact cards are all displayed in the card 

15 display area in a common format, namely, an electronic business card format. 

Next, the rolodex processing 1000 determines 1004 those communication 
mechanisms available to the operating system and also the selected contact card. Here, the 
individual contact cards can control whether certain communication mechanisms are able to 
be used to contact the individual associated with the contact card. For example, the 
20 commimication mechanisms may include telephone, facsimile, and email. Other possible 
communication mechanisms are video conference, on-line chat, and Internet telephony. In 
one embodiment, the block 1 004, those communication mechanisms that the operating 
system can support are first determined, and then from the communication mechanisms that 
the operating system supports, it is determined which are permitted by the selected contact 



In FIG. 18C, the communication mechanisms is a screen illustration of a 
representative rolodex feature according to an embodiment of the invention. In the screen 
illustration, icons 1818-1828 represent potentially available commimication mechanisms 
for the representative rolodex feature. Following block 1004, the identified or determined 
30 communication mechanisms that are available are distinguishably displayed 1006 from 

those communication mechanisms that are unavailable. As an example, if the contact card 
specifies that facsimile and email are permitted but telephone is not permitted, then visual 
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card. 
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indicators representing the communication mechanisms associated with facsimile and email 
would indicate availability while the communication mechanism associated with telephone 
would be disabled. In one embodiment, the visual indicators representing the 
communication mechanisms are icons (e.g., icons 1818 - 1828) that are displayed by the 
client-side application of a display screen. These icons are then either "grayed-out" or 
shown as active depending upon their availability (with respect to the both the operating 
system and the selected contact card). 

Following block 1006, a decision block 1008 determines whether a user has selected 
one of the available communication mechanisms. When the user has not selected one of the 
available communication mechanisms, then the rolodex processing 1000 is able to return to 
repeat the block 1002 such that the user is able to select a different contact card than the one 
previously selected and continue the processing. On the other hand, when the decision block 
1008 determines that the user has selected one of the available communication mechanisms, 
the rolodex processing 1000 initiates 1010 communication to the entity associated with the 
selected contact card via the selected communication mechanism. For example, if the user 
selected the visual indicator representing the communication mechanism for email, the 
initiation 1010 of the email communication would present a message generation screen 
where a user would enter a message for the email to be sent. Thereafter, the email message 
would be sent to the email address associated with the selected contact card. As another 
example, if the user selected the visual indicator representing the communication mechanism 
for telephone, the initiation 1010 for the telephone communication would, for example, dial 
the phone number associated with the selected contacts card via computer or Internet 
telephony. Following block- 1010, the rolodex processing 1000 is complete and ends. 

Hence, the rolodex processing 1000 allows a user of the client-side application to 
easily and rapidly identify an entity (e.g., a person, company or group) that he/she wishes to 
contact (or at least reference information on the entity for other purposes). The rolodex 
processing 1000 additionally allows the user of the client-side application to also initiate 
communication with the entity associated with a selected contact card. This facilitates the 
ease of use of the system because the same application not only identifies the appropriate 
contact persons but also permits the communication to those entities in a manner in which 
they have previously authorized. 
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As noted above, a registered user can select commiinication mechanisms (channels) 
using the client-side application. However, the availability of the communication 
mechanisms is limited by those supported by the operating system and by those 
communication mechanisms that have been permitted by the associated contact information. 
The client-side application is able to connect to the system server by making a socket 
connection as is well known in the art. The conununication protocol being used between the 
system server and the client-side application as implemented by a network interface can, for 
example, utilize communication protocol such as COM, CORBA, or TCP/IP. When 
accessing the server website through a network browser, users access the website server 
using HTTP requests. 

The information management and exchange system also provides for automatic 
distribution (e.g., exchange) of profile information between registered users in a controlled 
manner. The requested exchanges of profile information are made between one client-side 
application and another client-side application located on different local machines. These 
different client-side applications are utilized by different users and communicate with one 
another through the server system. When the requested party receives an exchange request, 
the requested party is able to accept or deny the exchange request. FIGs. 11-13 are 
provided to explain the exchange processing according to the invention. 

FIG. 1 1 is a flow diagram of requestor exchange processing 11 00 according to an 
embodiment of the invention. The requestor exchange processing 1 100 is, for example, 
performed by the client-side application running on a local machine when a user of the 
client-side application desires to exchange contact information with another. 

The requestor exchange processing 1 100 begins with a decision block 1 102. The 
decision block 1 102 determines whether an exchange is requested. When the decision block 
1 102 determines that an exchange has not been requested, then the requestor exchange 
processing 1 100 awaits such a request. In other words, the requestor exchange processing 
1 100 is not invoked until an exchange request is received. 

Once an exchange has been requested, the requested party for the exchange is 
identified 1 104. In one embodiment, the requested party with which the requestor desires to 
exchange profile information (e.g., business card information) is identified by first and last 
name as well as an email address. In other embodiments, more or less information can be 
used so long as the requested party is able to be determined without ambiguity. Afl:er 
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identifying the requested party, an exchange request is submitted 1 106 to the server system. 
The server system can then process the exchange request and inform the requestor exchange 
processing 1100 whether a response has been received to the exchange request. A decision 
block 1 108 determines whether a server response has been received to the exchange request. 
When the decision block 1 108 determines that a server response has not yet been received, 
the requestor exchange processing 1 100 awaits the reception of such a response. Once the 
decision block 1 108 determines that a server response has been received, the status of the 
exchange request is displayed 1110. As an example, the status of the exchange request can 
be either: accepted, waiting or denied. Often, there will be more than one exchange request 
pending, so that the status of each of the exchange requests are displayed 1110. Hence, the 
requestor is able to observe the status of the one or more uncompleted exchange requests 
that it has made. Following block 1110, the requestor exchange processing 1 100 is 
complete and ends. 

FIGs. 12A and 12B are flow diagrams of requested party exchange processing 1200 
according to an embodiment of the invention. The requested party exchange processing 
1200 is, for example, performed by the client-side application running on the local machine 
associated with the requested party. 

The requested party exchange processing 1200 initially displays 1202 a list of 
requestors that have requested to exchange profile information. The requested party is then 
able to select 1204 one of the requestors in the list of requestors being displayed. Then, the 
requested party exchange processing 1200 awaits a user selection. A decision block 1206 
waits for the requested party to make a user selection. Once the decision block 1206 
determines that a user selection has been received, a decision block 1208 determines 
whether the user selection is to exit the requested party exchange processing 1200. When 
the decision block 1208 determines that the user selection is to exit, then the requested party 
exchange processing 1200 is complete and ends without having operated to accept or decline 
any of the requestors that have requested to exchange profile information. 

When the decision block 1208 determines that the user selection is not to exit, a 
decision block 1210 determines whether the user selection is to accept the requested 
exchange by the selected requestor. When the decision block 1210 determines that the user 
selection is to accept the requested exchange, then a niessage is sent 1212 to the server 
system informing the server system to accept the particular exchange. Following block 
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1212, the displayed list of requestors is updated 1214. In one embodiment, the update to the 
displayed list operates to remove the selected entry in the list of the requestors being 
displayed. Following block 1214, the requested party exchange processing 1200 retums to 
repeat the block 1204 and subsequent blocks. 

5 On the other hand, when the decision block 1210 determines that the user selection is 

not to accept the exchange request from the selected requestor, a decision block 1216 
determines whether the user selection is to decline the exchange request from the selected 
requestor. When the decision block 1216 detemiines that the user selection is to decline the 
exchange request from the selected requestor, a message is sent 1218 to the server system to 

10 decline the exchange. Following block 1218, the requested party exchange processing 1200 
retums to repeat the block 1214 and subsequent blocks where the list of the requestors being 
displayed is updated and then processing for another of the requestors can be performed. 

Alternatively, when the decision block 1216 determines that the user selection is not 
to decline, then a decision block 1220 determines whether the user selection is to accept the 

15 exchange request with limitations. When the decision block 1220 detemiines that the user 
selection is not to accept with limitations, then the requested party exchange processing 
1200 retums to repeat the block 1204 and subsequent blocks. When the decision block 1220 
determines that the user selection is to accept the exchange request with limitations, a 
limitation screen is displayed 1222. Then, the requested party is able to select 1224 limits 

20 for the exchange. Next, a message is sent 1226 to the server system informing the server 

system to accept the exchange request by the selected requestor with the selected limitations. 
Following block 1226, the requested party exchange processing 1200 retums to repeat the 
block 1214 and subsequent blocks. 

Once the server system is notified that a requested party has agreed to accept an 

25 exchange request, the server system operates to send a status update to the particular 

requestor. The status update can, for example, be forwarded to the client-side application of 
the requestor when next connected with the server system. The status update will update the 
status of the pending exchange requests of the particular requestor. 

FIG. 18D is a screen illustration of a representative limitations screen according to an 

30 embodiment of the invention in which various exchange options can be selected (block 
1222). In the screen illustration, the requested party is accepting the request to exchange 
profile information with the limitations that only the restricted personal information of 
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address and email (as well as name) are pemiitted to be exchanged. Other limitations 
screens can be used. 

Further, the users could process the limitations of exchanges by categorizing the 
requestors into groups. Exemplary groups are family, business associates, and friends. Each 
5 of the groups would have the exchange settings set based on the type of group. For 

example, family might be exchanged without limitations, friends might be exchanged with 
minor limitations, and business associates might have more limitations. Then, when 
accepting an exchange request, the requested party simply selects the appropriate for the 
requestor and the limitations on the exchange are thereby determined. 

10 Additional modification to the requested party exchange processing can limit the 

number of requests for exchanging information a requested party has to respond to. One 
approach is for the requested party to set a preference that a password be required to be 
entered by a requestor of an exchange. Here, upon submitting a request for exchange, the 
server would determine that the requested party has required a particular password in order 

15 to permit such requests. Hence, the server would cause the client-side application to query 
the requestor to enter the password. If the requestor enters the correct password, then the 
server forwards the request to the requested party. On the other hand, if the requestor fails to 
enter the correct password, the request is never sent to the requested party. This approach is, 
for example, suitable for a requested party that wants to limit the exchanges to persons it has 

20 provided the password. 

FIG. 1 8 J is a screen illustration of a representative limitations screen according to an 
embodiment of the invention in which various exchange options can be selected based on 
groups. The client-side application enables the user to profile himself with information 
ranging from business to personal information. Because of the nature of contacts, such 

25 information may not be equally shared with all contacts. Therefore, the client-side 

application can allow a user to create different groups of contacts, each with a list of user 
selectable exchange options for that group profile. For example, a user may create a 
Business Group that contains only Business information and another group called Close 
Friends that contains both Business and Personal information. FIG. 18 J, for example, 

30 illustrates the user exchange selections being made for the group denoted Close Friends. 
Thereafter, whenever a request for contact information is received by the user, the user is 
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free to select that particular profile group that the requestor should be designated. The 
profile information related to the selected group can then be sent to the system server 
together with the permission to distribute (or exchange). The system server then deliver the 
appropriate profile information to the requestor. As noted above, a password control option 
can also be implemented. The password control can be associated with the definition of the 
group profiles. For example, if the user is well known in her industry, she can be given the 
option of picking a password such that when a request for contact information arrives at the 
server system, the server system will first ask the requestors to provide the password. If the 
requestor does not enter the correct password, no request (e.g., exchange request) is 
forwarded to the user. The password option would allows for increased privacy and 
reduction in xmwanted requests (e.g., spam). 

Another approach is for the requested party to pre-approve exchange requests. For 
example, a sales person often wants a wide distribution of their contact information to 
anyone willing to accept it. Hence, by pre-authorizing such exchanges of such business 
information, the sales person need not individually approve the exchange requests. 

FIG. 13 is a flow diagram of requestor exchange completion processing 1300 
according to an embodiment of the invention. The requestor exchange completion 
processing 1300 is, for example, performed by the client-side application running on the 
local machine associated with the requestor. 

The requestor exchange completion processing 1300 begins with a decision block 
1302. The decision block 1302 detemiines whether a status update has been received. Here, 
the status update is supplied by the server system to the client-application running on the 
local machine. When the decision block 1302 determines that a status update has been 
received, the status of the one or more exchange requests being displayed are updated 1304 
in accordance with the status update. Otherwise, when the decision block 1302 determines 
that status update has not been received, the block 1304 is bypassed and the client-side 
application may otherwise operate to display the previous status of the one or more 
exchange requests. In any case, once the one or more exchange requests are displayed and 
updated as appropriate, the requestor is able to select 1306 one of the exchange requests. 

A decision block 1308 then determines whether the status of the selected exchange 
request is "pending". When the decision block 1308 determines that the status of the 
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selected exchange request is "pending", then a decision block 1310 determines whether the 
requestor desires to exit the requestor exchange completion processing 1300. When the 
decision block 1310 determines that the user does desire to exit, then the requestor exchange 
completion processing 1300 is complete and ends. On the other hand, when the decision 
block 1310 determines that the user does not desire to exit, then the requestor exchange 
completion processing 1300 returns to repeat the decision block 1302 and subsequent 
blocks. 

Alternatively, when the decision block 1308 determines that the status of the selected 
exchange request is not "pending", then a decision block 1312 determines whether the status 
of the selected exchange request is "accepted". When the decision block 1312 determines 
that the status of the selected exchange request is not "accepted", then a message indicating 
that the exchange is not permitted is displayed 1314. In this case, the status of the selected 
exchange request is "denied". Hence, following block 1314, the requestor exchange 
completion processing 1300 returns to repeat the decision block 1302 without completing 
the selected exchange request. 

On the other hand, when the decision block 1312 determines that the status of the 
selected exchange request is "accepted", then the requested party's profile is requested 1316 
from the server system. Then, a decision block 1318 determines whether the requested 
profile has been received. The decision block 1318 causes the requestor exchange 
completion processing 1300 to await the arrival of the requested party's profile. Once the 
requested party's profile has been received, the requested party's profile is stored 1320 on 
the local machine. At this point, the requested party's profile (e.g., business card) is stored 
on the local machine and therefore available to the rolodex feature and thus available to the 
client-side application program. The status of the displayed exchange request is also 
updated 1322. Namely, the entry in the list of the displayed exchange requests that are 
pending can be removed since the exchange of profile information has been completed. 
Following block 1322, the requestor exchange completion processing 1300 retums to repeat 
the decision block 1302. 

As discussed above with respect to FIGs. 12A and 12B, the requested party exchange 
processing 1200 can be performed via the client-side application. In which case, the 
requested party can choose to accept, decline or accept with limitations each of the particular 
requests for exchange of profile information. An altemative approach is for the requested 
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party to perform similar actions upon receiving an email message from the system server. 
FIG. 14 is a flow diagram of requested party exchange processing 1400 through electronic 
email according to an embodiment of the invention. The requested party exchange 
processing 1400 begins when the requested party receives 1402 an exchange authorization 
email from the system server. The requested party then reads 1404 the exchange 
authorization email and decides how to respond to it with respect to a particular 
authorization type. Then, the requested party selects 1406 one of accept, decline or accept 
with limitations. An email reply is formed 1408 containing the requested party's 
authorization selection. The reply email is then sent 1410 to the system server. Following 
block 1410, the requested party exchange processing 1400 is complete and ends. For each 
exchange request, the server system would cause an exchange authorization email to be sent 
to the appropriate requested party in the manner discussed above. 

FIGs. 18E-18H are screen illustrations of representative screens provided to users 
during the exchange processing pertaining to FIGs. 11-13 according to an embodiment of 
the invention. FIG. 18E illustrates a representative exchange screen in which a requestor 
identifies (block 1 104) the requested party they desire to exchange profile information with. 
Specifically, a requested party identification area 1830 is provided on the representative 
exchange screen and the requestor enters the identifying information (e.g., first name, last 
name, and email address). To submit (block 1 106) the exchange request to the system 
server, the requestor selects a submit button 1832. FIG. 18E illustrates a representative 
exchange screen in which an exchange status area 1834 displays the status of those 
exchanges that the requestor has requested and which are in process (block 1110). Here, an 
entry 1836 in the exchange status area 1834 indicates that currently a single exchange 
request (the one just submitted) is "waiting". To refresh the status information provided in 
the exchange status area 1834 a status button 1838 can be depressed. Alternatively, the 
server system could refresh the status information as desired when the requestor is connected 
to the server system. FIG. 18G illustrates a representative exchange screen for the requested 
party of the exchange request. The representative exchange screen for the requested party 
includes a requested exchange area 1840. In this example, the requested exchange area 1840 
includes an entry 1842 that indicates that a particular requestor has submitted a request to 
exchange profile information with the requested party (block 1202). The particular 
requestor is identified by the entry 1842 (e.g., first name, last name, and email address). To 
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refresh the requested exchange area 1840 a refresh button 1844 can be depressed. Upon 
selecting the entry 1842 in the requested exchange area 1840, the requested party then 
decides whether to accept or decline the request. A authorization area 1846 on the 
representative exchange screen of FIG. 18G includes an accept button 1848 and a decline 

5 button 1850. The requested party selects the accept button 1 848 to permit the requested 
exchange (block 1210), and selects the decline button 1850 to deny the requested exchange 
(block 1216). In another embodiment, a third button can be provided to accept with 
limitations, where the limitations are provided by a limitations screen such as shown in FIG. 
18D. Finally, FIG. 18H illustrates a representative exchange screen for the requested party 

10 in which the exchange status area 1 834 has been updated (block 1304) after the requested 
party has authorized the requested exchange. Namely, displayed status of the outstanding 
exchange that the requestor has requested (the entry 1836) is now "accepted''. At this point, 
the requestor can depress a download button 1852 to complete the exchange request by 
causing the requested profile of the requested party to be received at the local machine of the 

15 requestor (block 1316). Alternatively, if the requestor should change their mind and no 
longer desire the exchange, then the requestor can depress a remove button 1854 to cancel 
the exchange request. 

During the registration process, a user or registrant will enter his/her contact or 
profile information. However, if at any time after registering the registrant desires to change 
20 their profile information, the client-side application facilitates such modifications. 

Additionally, the updated profile will be able to be automatically distributed to all of those 
registered users that have previously received the profile that has now been updated. 

FIG. 15 is a flow diagram of change profile processing 1500 according to an 
embodiment of the invention. The change profile processing 1500 is, for example, 
25 performed by the client-side application on the local machine. 

The change profile processing 1500 initially displays 1502 a current local user 
profile. The user of the local machine can then determine how to modify the current local 
user profile. The displayed user profile is then modified 1504. The use is able to modify 
any of the information forming part of the profile that they previously provided. 

30 FIG. 1 81 illustrates a representative update profile screen that can be displayed by the 

client-side application (block 1502). The representative update profile screen includes a 
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current profile data section 1854 that displays current data, and a new profile data section 
1856 where the user can enter the modifications to the profile (block 1504). 

Following block 1504, a decision block 1506 determines whether the user has 
requested to save the modified profile. When the user does not wish to save the modified 
5 profile, then a decision block 1508 determines whether an exit is being requested. When the 
decision block 1508 determines that an exit is requested, then the change profile processing 
1500 is complete and ends without modifying the user profile. On the other hand, when the 
decision block 1508 determines that the user is not requesting an exit, then the processing 
retums to repeat the block 1504 and subsequent blocks so that additional modifications can 
10 be made to the displayed user profile. 

Alternatively, when the decision block 1506 determines that the modified profile is 
to be saved, then the modified profile information is sent 1510 to the server system. Then, a 
decision block 1512 determines whether the server user profile has been successfully 
updated in accordance with the modified profile information that was sent 1510 to the 
15 system server. When the decision block 1512 determines that the server user profile has 

been successfully updated, then the local user profile is updated 1514 based on the modified 
profile information. At this point, the appropriate user profile has been updated on both the 
system server and the local machine. Following block 1514, the change profile processing 
1500 is complete and ends. 

20 On the other hand, when the decision block 1512 determines that the server user 

profile has not been successfully updated, an error message is displayed 1516 on the display 
screen of the local machine to indicate that the profile has not been updated. Then, a 
decision block 1518 determines whether a retry is desired. When a retry of the update to the 
user profile is requested, the change profile processing 1500 retums to repeat the block 1510 

25 and subsequent blocks. Alternatively, when the decision block 1518 determines that a retry 
is not desired, then the change profile processing 1500 is complete and ends without having 
updated the user profile. 

In FIG. 15, the user profile was updated by way of the client-side application running 
on the local machine. However, an altemative approach would allow a registrant to modify 
30 his/her user profile using the server website associated with the information management 
and exchange system. In such a case, the user at the local machine could use a network 
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browser (e.g., web browser) to access the server website. Then, the user could sufficiently 
identify him/herself to the server website (such as with his/her name and PID and possibly 
password). Once identified to the server website, the current user profile would then be 
displayed and the user would be allowed to modify and submit the modified user profile to 
the system server. 

At this point, the user profiles that have been modified are stored on the system 
server, but the outdated user profiles that have been previously exchanged with other 
registered users remain out of date. FIGs. 16 and 17 described below indicate one 
embodiment for updating the user profiles that have been previously exchanged in an 
automated fashion. 

FIG. 16 is a flow diagram of update profile processing 1600. The update profile 
processing 1600 is performed on the system server. The update profile processing 1600 can 
be initiated every time a modified user profile is submitted to the system server or can 
periodically operate on the system server. As illustrated in FIG. 16, the update profile 
processing 1600 initially begins with a decision block 1602 that determines whether any 
profiles have been updated. When there are no profiles that have been updated, the update 
profile processing is not invoked. However, when the decision block 1602 determines that 
one or more profiles have been updated on the system server, then the update profile 
processing 1600 is invoked. 

Once the update profile processing 1600 is invoked, one of the updated profiles is 
selected 1604. Then, all registered users who have previously received a copy of the 
outdated profile are identified 1606. As an example, the user profiles can be stored in the 
server contact information storage 216 such that each registrant is stored in a database along 
with a list of those registered users that previously obtained a copy of the now outdated 
profile. Next, an update flag is set 1608 for each of the identified registered users. For each 
registrant, the update flag indicates that one or more of the user profiles it has stored locally 
needs to be updated. This update flag will be used to subsequently update the user profiles 
stored on the local machine. 

A decision block 1610 then determines whether there are more profiles to be 
updated. When the decision block 1610 determines that there are more profiles to be 
updated, then the update profile processing 1600 retums to repeat the block 1604 and 
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subsequent blocks. On the other hand, when the decision block 1610 determines that there 
are no more profiles to be updated, then the update profile processing 1600 is complete and 
ends. 

FIG. 17 is a flow diagram of initial server connection processing 1700 according to 
an embodiment of the invention. The initial server connection processing 1700 is, for 
example, performed by the server system. The initial server connection processing 1 700 
commimicates with the local machines to manage profile updates and exchange requests. 

The initial server connection processing 1700 is invoked when a user of the client- 
side application connects to the system server. A decision block 1702 determines whether a 
registered user has connected. When the decision block 1702 determines that a registered 
user has not connected, then the initial server connection processing 1700 is not invoked. 
Once a registered user has connected to the system server, the initial server connection 
processing 1 700 is invoked. 

When the initial server connection processing 1700 begins, a decision block 1704 
determines whether an update flag is set. The update flag for the various registrants is set in 
block 1608 of FIG. 16 to signal that one or more user profiles that have previously been 
exchanged have been modified. Hence, the decision block 1704 determines whether the 
registrant that has connected to the system server needs to be sent user profiles that have 
been modified. When the decision block 1704 determines that the update flag is set, then 
updated user profiles for those previously exchanged user profiles that have been updated 
are sent 1706. On the other hand, when the decision block 1704 determines that the update 
flag is not set, then block 1706 is bypassed because the user profiles that have been 
exchange with the registrant have not been modified. 

In an altemative embodiment, instead of sending 1 706 the updated user profiles, the 
server system could merely send an update notification to the client-application of the local 
machine that there are updated profiles to be delivered. This approach allows the user to 
decide if and when the updated user profiles are to be sent. In one implementation, the 
update notification could display a flashing update indicator to signal the user that updated 
profiles are waiting to be delivered. For example, in FIG. 19 A, an indicator 1912 can be 
used to signal the user of the client-side application when updates are waiting. In another 
implementation, the update notification could display the names of the registrants having the 
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updated profiles that are waiting to be delivered. As an example, in FIG. 19A, an update 
button 1914 is then available for the user to depress when the user desires to receive the 
updates. In still another implementation, the server system could resend all of the user 
profiles that have been previously exchanged with the registrant; however, such an approach 
5 would be less efficient. 

Following block 1706, as well as following the decision block 1704 when the update 
flag is not set, a decision block 1708 determines whether there has been a status change. 
The status change pertains to the status of pending exchange requests which the registrant 
that has connected to the system server has previously requested. When the decision block 
10 1708 determines that there have been status changes, then status information on the pending 
exchange requests is sent 1710 to the local machine. This status information is, for example, 
used in the block 1110 of FIG. 1 1 where the status of the one or more pending exchange 
requests is displayed. Altematively, when the decision block 1708 determines that there has 
been no status change, then the block 1710 is bypassed. 

15 Following the block 1710, as well as following the decision block 1708 when there 

has been no status change, a decision block 1712 determines whether there are any incoming 
exchange requests. The incoming exchange requests are those exchange requests in which 
the registrant that has connected to the system server is the requested party. When the 
decision block 1712 determines that there are incoming exchange requests, a list of 

20 requestors that have requested to exchange profiles is sent 1714 to the local machine 

associated with the registrant that has connected to the server system. As noted above, the 
list of requestors is displayed to the registrant so that the requested party exchange 
processing can be performed as shown in FIGs. 12A and 12B. When the decision block 
1712 determines that there are no incoming exchange requests, then the block 1714 is 

25 bypassed. Following block 1714, as well as following the decision block 1712 when there 
are no incoming exchange requests, the initial server connection processing 1700 is 
complete and ends. 

Previously, as discussed above, the contact information provided by a user was self- 
representative by the user. The self-representative nature of the contact information means 
30 that the user is able to claim association with any organization or no organization at all. 



37 






Att. Dkt No.: CTClPOOl ^^^p ^ 

However, in some cases, some or all of the contact information is not set by the user but is 
instead set and controlled by an administrator of an entity. 

It is not uncommon for an individual to desire to have multiple representations 
depending upon the particular setting in which he/she is operating. For example, an 
individual may have a personal setting in which he/she wishes to distribute contact 
information, may also have a small business in which he/she operates, and may further be 
associated with a corporation of which he/she is an employee and thus be associated with 
contact information associated with the corporation. Hence, the information and exchange 
system allows a user to create multiple profiles of him/herself using the same client-side 
application. 

The users of the client-side application are able to represent themselves irrespective 
of employment (current or future). The user first and foremost represents himself primarily 
because of his unique ID (PED) assigned to him by the server system. The user profiles 
himself with his self-represented contact (profile) information. The user can also create 
further representations (profile) of himself. For example, the user may want to create 
another profile of himself as coach of his son's roller hockey team. FIG. 18K is a 
representative screen illustration 1858 of a user that has multiple representations according 
to an exemplary embodiment of the invention. The representative screen illustration 1858 
includes a first representation 1 860 pertaining to a business entity associated with the user, 
and a second representation 1862 pertaining to a personal association for the user. Here, the 
user can be represented, £ind thus exchange or distribute contact information, as either the 
president of Sound Minds Tech, Inc. or the coach of Pee Wee Roller Hockey. As shown in 
the representative screen illustration, a select representation is designated by a representation 
indicator 1864 or by the depression of the first representation 1860. The selected 
representation in a multiple representation situation is the one used during exchanges of 
contact information. In addition, the same user can also be officially represented as an 
employee of a corporation that has subscribed for the information management and 
distribution service. The user is subscribed as an employee and uses an official company 
business card, complete with company logo and only company editable employee 
information. The user now has an additional representation and is still imiquely identified as 
the same person to the server system; irrespective of changes in personal represented 
information or business entity information. 
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Typically, the system can distinguish between the different profiles by using the PID 
which is shared among the profiles together with the email address associated with the 
different profiles. In such case, the email address is different for each of the different 
profiles. Alternatively, an expanded PID could be used as a sub-profile reference to identify 
one of the different profiles. For example, if the user had a PID of 010, then the expanded 
PID for a business profile could be referenced as 010-1 ("-1" can be considered an 
extension), the expanded PID for a personal profile could be referenced as 010-2, and the 
expanded PID for a corporation profile could be referenced as 010-3. 

FIG. 19A is a representative screen illustration of a rolodex feature according to 
another embodiment of the invention. The screen illustration shows a rolodex icon 1900 as 
being selected, thus indicating that the client-side application is in the rolodex feature mode. 
The screen illustration includes a card display area 1902 that displays the contact card for the 
registered user. In a case of multiple representations, the registered user could have a 
personal contact card, a business contact card and a corporation contact card. To facilitate 
the registered user in selecting between the multiple profiles on the client-side application, 
selection buttons 1904 - 1908 are displayed on the screen illustration shown in FIG. 19 A. 
The selection button 1904 selects the personal profile, the selection button 1906 selects the 
business profile, and the selection button 1908 selects the corporation profile. As shown in 
FIG. 19A, the card display area 1902 is displaying the business profile associated with the 
registered user. 

Each of the one or more profiles that are associated with a registered user can contain 
information beyond the contact information. This additional information can be of a variety 
of types and formats. For example, the additional information can pertain to text, images, 
graphics, video and other multimedia types. The additional information also could be 
packaged within a HTML wrapper that would contain references or links to the additional 
information. The additional information could also be provided as additional cards. As 
shown in FIG. 19 A, the card display area 1902 includes an additional information 
designation area 1910 that informs the user whether there is additional information 
associated with the currently selected contact card being displayed in the card display area 
1902. The additional information designation area 1910 illustrated in FIG. 19A shows that 
the selected contact card has four additional cards of information associated therewith. By 
selecting one of the additional cards, the additional information or links to the additional 
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information are displayed in the card display area 1902. In the case of links, the links can 
point to either a local database of information or a remote server. 

FIG. 19A-1 is a representative screen illustration of an additional card 1920 of 
information according to an exemplary embodiment of the invention. The additional card 
5 1920 contains a link 1922 to a website, a multimedia button 1924 for an audio or video clip, 
various text objects 1926, and a graphic (picture) 1928. Additional cards (or deck) can thus 
be created, edited and viewed using the client-side application. The additional cards can be 
composed to include objects such as text, graphics (pictures), links, video, audio, tables, 
frames, etc. 

10 Hence, while the contact information may be represented in the form of a 

common display format (such as a business card format), additional information can be 
associated with the common display format . The common display format serves as a 
reference point for information that originates from a user or a business entity; essentially 
the point of contact. Every user and their contacts would use the same display format to 

15 reference their contacts. In one embodiment, the common display format is a card. Those 
cards holding additional information can be referred to as container cards. The invention 
also allows the users to embed additional information when they exchange or impart their 
contact information or profile through use of cards. The additional information may contain 
any number of data types, including text, graphics, images, multimedia (audio/video), 

20 telephony, fax, HTML, XML, Applets, and http links. These data types can reference 

datatypes or data objects within the same card or within a deck of cards (local or remote). 
The user may also add multiple cards, each card may be linked to the previous card. The 
ability to embedd new datatypes within the context of additional container cards referenced 
to the reference card truly makes all data types representable and presentable to all parties in 

25 a consistent manner. The ability of container cards to embedd common datatypes that 
possess the ability to affect other datatypes within the same container card, or within the 
same deck or on remote machines provides an extremely powerful architecture. 

The embedded data types may be visible or invisible and may be added either at 
30 design time or added dynamically at run time. The container cards may be as simple as 

XML/HTML code that can simply be imported from some standard XML/HTML parser or 
can themselves be entire applications and Applets (Java) v/rapped together and represented 
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in the common display fomiat. A data type object is a higher class abstraction of a data type 
with predefined behaviour properties that when executed, perform some pre-defined actions 
and events. Additionally, these events are able to influence and affect the behavior of other 
objects within the same card, deck of cards or within objects embedded in cards on remote 

5 servers that are programmed to understand common events and actions. For example, an 
audio data type object is a class of audio object whose format is of ".wav" and of type: 8 bit 
compressed. The format and type are properties that may be set at design or run time. The 
same audio object has multiple predefined events that are fired at the relevant point in the 
execution of the run time behavior of the object. For example, the audio object has been 

10 preset to play ADPCM 16 bit files and has been defined to understand the following events: 
OnClick, OnStartAudio, OnEndAudio, OnPauseAudio. As an example, this audio object can 
be embedded in a container card with an image object that is programmed with design/run 
time properties that will present a *slide-show' synchronized to the OnClick, OnPauseAudio 
and OnEndAudio of certain music segments being played. 

15 The client-side application allows these *Deck of Cards' to be easily created. Each 

card can be given a name and referenced by that name. For each card, the user may add the 
required data types by first selecting the data type (e.g., text, graphics, audio, etc.) and then 
clicking on a canvas area for the card. Once the data type is dropped onto the canvas area, it 
can be dragged and placed at the desired location. By double clicking that data type icon, a 

20 new dialog window is presented that will be used to select additional properties or input data 
for that data type. For example, when a text data type is dropped on the canvas area, a 
double click action brings up a dialog window where the text string may be entered, together 
with the ability to dictate properties such as font size, font color, etc. Similarly, when a link 
data type is selected and placed onto the canvas area, a double click action brings out a 

25 dialog box that permits the user to enter an address related to the text link (or bitmap link) 
that can be a redirection to a remote web site or it could be a local reference to a HTML file. 

The information management and distribution system can also include a corporate 
administrator application. The corporate administrator application is downloaded or 
obtained in ways similar to how the client-side application is obtained as discussed above. 
30 An administrator operates the corporate administrator application which executes on the 
local machine associated with the administrator. The corporate administrator application 
can include many of the features associated with the client-side application, including 
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creation and design, rolodex, exchange, and update features. For example, the administrator 
may wish to update a corporate contact that has been previously distributed or exchanged. 

FIG. 19B is a block diagram of a network information management and distribution 
system 1950 according to another embodiment of the invention. The network information 

5 management and distribution system 1950 is generally similar to the network information 
management and distribution system 100 illustrated in FIG. 1. Additionally, however, the 
network information management and distribution system 1950 includes an administrator 
machine 1952 that connects to the Intemet 108 through an intermediate 1954. The 
administrator machine 1952 administers information and management of information 

10 pertaining to a business entity. The intermediate 1954 can refer to any of a number of 

networks or network devices, including a Local Area Network (LAN), a corporate Intranet, a 
Wide Area Network (WAN), a wireless data network, and an Intemet Service Provider 
(ISP). It should be noted that other networks besides the Intemet can be used to interconnect 
the server machine 102 with the administrative machine 1952. Here, the server machine 102 

15 provides for storage and management of content information for a plurality of users. The 
content information can pertain to not only individuals but also corporate users. 

The distribution of the content information at the server machine 102 can be operate 
as described above. Alternatively, the distribution of the corporate contact information can 
be performed as follows. First, the user of the requestor machine 104 makes a request for 

20 corporate contact information to the server machine 102 through the Intemet 108. Second, 
when the server machine 102 receives the request from the requestor machine 104, the 
server machine 102 determines that the requestor is seeking to receive the corporate contact 
information for the user of the requested party machine 106. In this example, the user of the 
requested party machine is also an employee of the business entity associated with the 

25 corporate contact information. As noted above, the user may have multiple representations 
such as personal, business and corporate. Here, the request would be to receive the 
corporate representation of the user (employee) with respect to their employer. Such a 
corporate representation would include the corporate contact information. The server 
machine 102 then proceeds to query the user of the requested party machine 106 whether the 

30 distribution of its corporate contact information is permitted. If the user of the requested 
party machine 106 replies that the distribution is permitted, then the server machine 102 
forwards the corporate contact information for the user of the requested party machine 106 
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from the server machine 102 to the requestor machine 104 through the Internet 108. Upon 
receiving the corporate contact information for the user of the requested party machine 106, 
the requestor machine 104 locally stores the corporate contact information in the requestor 
machine 104. Altematively, if the user of the requested party machine 106 replies that the 
5 distribution is not permitted, then the server machine 102 sends a notification to the 

requestor machine 104 to inform the user that the request for corporate contact information 
from the user of the requested party machine 106 is denied. Optionally, instead of the one- 
v^ay distribution of the contact information, contact information of both users of the 
requestor machine 104 and the requested party machine 106 can be exchanged (i.e., two-way 
10 distribution). 

Accordingly, the distribution of corporate contact information is controlled by the 
"ovmer" of the information which would normally be an employee. As such, contact 
information is able to be electronically transmitted to those users that are approved and not 
to those users that are not approved. However, the administrator of the corporate contact 

15 information is responsible for control over at least the basic corporate contact information so 
that the corporate image (e.g., appearance, logo, etc.) are consistent and centrally controlled. 
The administrator also is able to limit availability of the contact information to employees. 

Additionally, should the contact information need to be changed, the changes can be 
made and then the server machine can proceed to update the previously transmitted contact 

20 information. As an example, the updating of the contact information at the administrator 
machine 1952 produces altered contact information that is forwarded and stored on the 
server machine 102. Then, the server machine 102 can distribute the altered content 
information through the Intemet 108 to all of those requestors machines that previously 
received (and this store) the contact infomiation which is now outdated, thereby updating the 

25 content information for the user of the requested party machine 106 on the various requestor 
machines. As an example, the administrator may update the corporate contract information 
to change the corporate address. In such case, those registered users having previously 
received would receive the updated corporate contact information (or at least a notification 
of its availability). In addition, the administrator can also cause notifications, 

30 announcements or advertisements to be distributed to registered users in any of a number of 
ways. The administrator can also disable contact information for particular employees of the 
business entity. 
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FIG. 20 is a flow diagram of corporate administrator application processing 2000 
according to an embodiment of the invention. The corporate administrator application 
processing 2000 is, for example, performed by a corporate administrator application. The 
corporate administrator application executes on an administrator machine (e.g., 

5 administrator machine 1952) associated with an administrator. More generally, the 

administrator machine is a local machine. The administrator is charged with administration 
of the information management and exchange system for the corporation (or other business 
entity). Although the administrator application is referred to as a corporate administrator 
application, it should be noted that the corporate administrator application is not limited to a 

10 corporation and thus any suitable business entity can be used. 

The corporate administrator application processing 2000 initially searches 2002 a 
local machine for a corporate identifier (CID). The local machine being searched is the local 
machine on which the corporate administrator application is installed. A decision block 
2004 then determines whether the CID has been found. When the decision block 2004 
15 determines that a CID has not been foimd, then local corporate registration processing is 
performed 2006. The local corporate registration processing causes the administrator to 
perform the corporate registration before the corporate administrator processing 2000 can 
perform its normal processing. Following block 2006, the corporate administrator 
application processing 2000 is restarted. 

20 Alternatively, when the decision block 2004 determines that the CID has been found, 

then the normal processing provided by the corporate administrator application 2000 can be 
performed. Namely, the local machine is connected 2008 to a server machine (e.g., the 
server machine 102). This connection is performed over a network. In one embodiment, the 
network includes the Intemet. Often, the network will also include a corporate network, 

25 such as a LAN, that connects the local machine to the Intemet. 

Next, a decision block 2010 determines whether the administrator desires to design a 
corporate contact card. The corporate contact card contains the contact information for the 
corporation (or other business entity). The corporate information is presented in a contact 
card that provides a common format for the information. When the decision block 2010 
30 determines that the administrator desires to design a corporate contact card, then processing 
to design corporate contact card processing is performed 2012. Following block 2012, the 
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corporate administrator application 2000 processing returns to repeat the decision block 
2010 and subsequent blocks. 

On the other hand, when the decision block 2010 determines that the administrator 
does not desire to design a corporate contact card, then a decision block 2014 determines 
whether the administrator desires to associate employees to the corporation. When the 
decision block 2014 determines that the administrator desires to associate employees to the 
corporation, processing to associate employees to the corporate contact card is performed 
2016. There are a variety of ways to associate employees to a corporation or the corporate 
contact card. Such ways include importing employee data into the corporate administrator 
application, manually entering the employee data by the administrator, or having the 
employees enter their employee information using their client-side application associated 
with their local machines. 

Altematively, when the decision block 2014 determines that the administrator does 
not desire to associate employees to the corporation, a decision block 2018 determines 
whether a notification request is being made. When the decision block 2018 determines that 
a notification request has been made, then notification and disable processing is performed 



On the other hand, when the decision block 201 8 determines that there has been no 
notification request, a decision block 2022 determines whether the administrator desires to 
disable employee cards. When the decision block 2022 determines that the administrator 
desires to disable employee cards, then disable employee cards processing is performed 
2024. Altematively, when the decision block 2022 determines that the administrator does 
not desire to disable employee cards, as well as following the block 2016, the block 2022 or 
the block 2024, a decision block 2026 determines whether an exit has been requested. When 
the administrator has requested to exit the corporate administrator application, the corporate 
administrator application processing 2000 is complete and ends. Altematively, when the 
decision block 2026 determines that the administrator has not requested to exit the corporate 
administrator application, the corporate administrator application processing 2000 returns to 
repeat decision block 2010 and subsequent blocks. 

Although not shown in FIG, 20, the corporate administrator application can also 
perform some or all of the fiinctions or features of the client-side application. For example. 



2020. 
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the functions or featxires include creation and design, rolodex, exchange, and update 
features. 

FIG. 21 is a flow diagram of local corporate registration processing according to an 
embodiment of the invention. The local corporate registration processing 2100 is, for 
5 example, the processing associated with the block 2006 illustrated in FIG. 20. The local 
corporate registration processing 2100 is performed on a local machine that is associated 
with an administrator of the information management and distribution system (e.g., the 
administrator machine 1952). 

The local corporate registration processing 2100 initially identifies 2102 a system 
10 administrator. The system administrator is the individual who will administer the 

information management and distribution system. In other words, the system administrator 
will be responsible for maintaining the corporate contact information as well as for 
supervising and verifying the usage of the corporate contact information by the various 
employees of the corporation. 

15 Following block 2102, a corporate profile screen is displayed 2104. Then, the 

administrator completes 2106 the corporate profile by interacting with the corporate profile 
screen being displayed to enter corporate profile information for a corporate profile. Next, a 
decision block 2108 determines whether the administrator has requested to submit the 
corporate profile to the server machine. When the decision block 2108 determines that the 

20 administrator has not requested to submit the corporate profile, then the processing returns to 
repeat the block 2106 and subsequent blocks. 

On the other hand, once the decision block 2108 determines that the administrator 
has requested to submit the corporate profile to the server machine, the local machine that 
performs the local corporate registration processing 2100 is connected 21 10 to the server 
25 machine. Then, the corporate profile information along with information pertaining to the 
system administrator are sent 21 12 to the server machine. 

Next, a decision block 2114 determines whether the corporate profile has been 
accepted by the server machine. When the decision block 2114 determines that the server 
machine has not accepted the corporate profile, then an error screen is displayed 21 16 on the 
30 local machine. Following block 2116, the local corporate registration processing 2100 
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returns to repeat the block 2106 and subsequent blocks so that the administrator can retry the 
creation and submission of the corporate profile. 

On the other hand, when the decision block 21 14 determines that the corporate 
profile has been accepted, the CID file is received 2118 from the server machine. Here, 
5 upon receiving the corporate profile that has been submitted, the server machine operates to 
produce a unique corporate identifier (CID). The CID file is then transmitted from the 
server machine to the local machine that is performing the local corporate registration 
processing 2100, Hence, in block 2118, the CID file is received 2118 from the server 
machine. Then, the CID file is stored 2120 on the local machine. The user is next instructed 
10 2122 to restart the corporate administrator application so that the processing performs the 
corporate administrator application processing 2000 illustrated in FIG. 20. Follov^ing block 
2122, the local corporate registration processing 2100 is complete and ends. 

The corporate profile information is typically presented to registered users in a card 
fomiat (i.e., corporate contact card). Specifically, a representative card format is a business 

15 card format. The designing of a corporate contact card is similar to the designing of a 

personal contact card and thus the processing described above with respect to FIG. 9 is also 
suitable for designing the corporate contact card. However, typically, a corporate contact 
card will include a company logo which is a particular graphic image that may be scanned or 
imported during the business card creation processing and thus placed on the corporate 

20 contact card. Additionally, as also noted above, additional information can be added to the 
contact cards or contact information associated with the cards. The additional information 
can take a variety of forms, including web page links, HTML documents, various messages, 
notifications and advertisements. 

FIG. 22 is a flow diagram of employee association processing 2200 according to an 
25 embodiment of the invention. The employee association processing 2200 is, for example, 
performed by the block 2016 illustrated in FIG. 20. The employee association processing 
2200 is also performed by the administrator of the information management and distribution 
system. 

The employee association processing 2200 initially begins with a decision block 
30 2202. The decision block 2202 determines whether the administrator desires to input 

employee data so as to create employee cards. When the decision block 2202 determines 
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that the administrator does desire to import employee data, then employee information is 
imported 2204 from a legacy database. Typically, a corporation will have a database that 
includes information about its employees. Hence, here, the ability to import employee 
information from such a database results in a substantial time savings in the registration of 

5 the employees with the information management and distribution system. Next, the 
employee association processing 2200 can operate to automatically create 2206 the 
employee cards (i.e., employee contact cards) using the employee information that has been 
imported. For example, while the corporate contact card has some common corporate 
contact information (e.g., corporate name, corporate address, company logo, etc.), the 

10 employee cards may need to add information such as employee name, title of job, work 
telephone number, work facsimile number and work email address. This type of 
information is often available from a legacy database and thus can be imported then used to 
automatically create the employee cards. Following block 2206, the employee cards are sent 
2208 to the server system. The server system is the central depository for all of the contact 

15 information associated with the information management and distribution system. Hence, 
the employee cards that have been created are sent 2208 to the server system. Following 
block 2208, the employee association processing 2200 is complete and ends. 

On the other hand, when the decision block 2202 determines that the administrator 
does not desire to import employee data, a decision block 2210 determines whether the 

20 administrator desires to manually enter one or more employees into the information 

management and distribution system. When the decision block 2210 determines that manual 
entry is desired, then one or more employee cards are manually created 2212. Following 
block 2212, the employee association processing 2200 performs the block 2208 and 
subsequent blocks. Alternatively, when the decision block 2210 determines that manual 

25 entry is not desired, then a decision block 2214 determines whether an exit is requested. 
When the administrator requests to exit the employee association processing 2200, the 
employee association processing 2200 is complete and ends. On the other hand, when the 
administrator does not desire to exit the employee association processing 2200, the 
employee association 2200 processing returns to repeat the decision block 2202 and 

30 subsequent blocks. 

Besides importing data or the administrator manually entering employee data, 
another approach is to have employees enter their employee information from their local 
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machines. Typically, the employees will also interact with the information management and 
distribution system using the client-side application executing on their local machine. In 
FIG. 19 A, for example, the corporate representation (employee card) could be selected for 
display by the client-side application by selection of the selection button 1908. Hence, by 
5 providing the employees with the corporate identifier (CID) and perhaps a password, the 
employees are able to individually create their own employee cards using the corporate 
profile as a base. Although the employee is able to build off of the corporate profile as a 
base, the corporate profile or card is not able to be altered by the employees. After the 
employees have created their employee cards using the corporate profile as a base, the 
10 employee cards would be sent to the administrator for approval and then, upon approval, the 
employee cards would be forwarded to the server system for storage. 

FIG. 23 is flow diagram of notification and disable processing 2300 according to an 
embodiment of the invention. The notification and disable processing 2300 is, for example, 
processing performed by the block 2020 illustrated in FIG. 20. 

15 The notification and disable processing 2300 begins with a decision block 2302. The 

decision block 2302 determines whether an announcement type notification is requested. 
When the decision block 2302 determines that an announcement type notification is 
requested, then an annoimcement is prepared 2304. After preparing the announcement, a 
distribution approach is selected 2306. As examples, the distribution approach can be email, 

20 facsimile, or as additional information associated with a contact card (e.g., a notification 
card). Then, a distribution request is sent 2308 to the server system. The distribution 
request operates to request that the server system distribute the announcement using the 
distribution approach selected to one or more of the registered users. 

On the other hand, when the decision block 2302 determines that an armouncement- 
.25 type notification is not requested, as well as following the block 2308, a decision block 2310 
determines whether an advertisement-type notification is requested. When the decision 
block 2310 determines that an advertisement-type notification is requested, then the 
notification and disable processing 2300 operates to prepare or retrieve 2312 an 
advertisement. Then, a distribution approach is selected 2314 for the advertisement. As 
30 examples, the distribution approach can be email, facsimile, or as additional information 
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associated with a contact card (e.g., a notification card). Next, a distribution is sent 2316 to 
the server system, requesting the distribution of the advertisement. 

Alternatively, when the decision block 2310 determines that an advertisement-type 
notification is not requested, as well as following the block 2316, a decision block 2318 

5 determines whether there is a request to disable a contact. When the decision block 23 1 8 
determines that there is a request to disable a contact, the employee card to be disabled is 
identified 2320. Then, the extent of disablement is determined 2322. For example, the 
disablement could be temporary or permanent. Also, the disablement could render the card 
inactive but still viewable, or could render the card totally unviewable, or could superimpose 

10 graphics or text on the card indicating that the card should no longer be used, etc. Following 
block 2322, a disable request is sent 2324 to the server system. 

On the other hand, when the decision block 23 18 determines that a disable request 
has not been received, as well as following the block 2324, a decision block 2326 
determines whether an exit has been requested. When the decision block 2326 determines 
15 that an exist has not been requested, then the notification and disable processing 2300 

returns to repeat the decision block 2302 and subsequent blocks. On the other hand, when 
the decision block 2326 determines that an exit has been requested, then the notification and 
disable processing 2300 is complete and ends. 



20 administrator application by either the requestor or the requested party could also be done by 
interacting with the website server using a network browser. The registration, rolodex, 
exchange (including request,, authorization and completion), and update could, for example, 
all be achieved by either or both of the client-side application or the network browser 
together with the website server. In the case of a network browser implementation, local 

25 storage (e.g., local contact information storage 316) of the contact information (and 
additional information) is not needed because such information is stored centrally not 
locally. In one network browser implementation, the client-side application (e.g., client-side 
application 306) is performed by scripts (e.g.. Javascripts or VB scripts) or plug-ins 
operating on the network browser or the website server, thus there is no need in such an 

30 implementation to download abd instal a client-side application. The client controller (e.g., 
client controller 302) can also be performed by scripts or plug-ins with the network browser. 



In general, any of the processing that could be done by the client-side application or 
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For example, in the case of an exchange request as noted above, the exchange of contact 
information can be initiated (blocks 1 104 - 1 106) by a requestor interacting with the client- 
side application. In such case, the requestor can, for example, enter the first name, last name 
and email address of the individual with whom an exchange of contact information is 

5 desired. However, when the exchange of contact information is initiated through the 

website server, the requestor would also need to identify him/herself to the website server. 
As an example, to initiate an exchange by way of the website server, the requestor would 
additionally need to indicate the first name, last name, the PID, and email address of the 
requestor himself. However, in all likelihood, the requestor would also be required to enter 

10 a password so that unauthorized exchanges do not occur. 

Security features can also be optionally provided with the invention. The security 
features can ensure that the registered users are provided with the opportunity to encode or 
encrypt information being transferred between the client-side application and the system 
server. The receiving side would then also be able to decode or decrypt the received 

15 information. 

Moreover, in some cases, a registered user may desire to interact with the system 
server using different remote machines. In such case, a password protected log in can be 
used to permit the user to access the system server. However, to keep the various client-side 
applications synchronized with the other client-side application or the interactions with the 
20 website server, the system server will store and eventually echo back all changes made 
during the remote log in. 

The advantages of the invention are numerous. Several advantages that 
embodiments of the invention may include are as follows. One advantage of the invention is 
that the distribution of information takes place in an automated fashion, which is particularly 

25 advantageous when large numbers of users are involved. Another advantage of the 

invention is that the parties involved in the distribution can control the distribution process 
so that only approved distributions occur. Still another advantage of the invention is that 
updates to previously distributed information can also be automated. Yet another advantage 
of the invention is that the information being exchanged is useful for enabling registered 

30 persons to efficiently contact the persons associated with the information using a mechanism 
which they have prescribed. Another advantage of the invention is that contact and 
additional information can be distributed to users in a common format. Still yet another 
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advantage of the invention is that an administrator can control the distribution and use of 
corporate (i.e., business entity) information. 

The many features and advantages of the present invention are apparent from the 
vvritten description, and thus, it is intended by the appended claims to cover all such features 
5 and advantages of the invention. Further, since numerous modifications and changes will 
readily occur to those skilled in the art, it is not desired to limit the invention to the exact 
construction and operation as illustrated and described. Hence, all suitable modifications 
and equivalents may be resorted to as falling v/ithin the scope of the invention. 

10 What is claimed is: 
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